[ワークショップ]「 可観測性とインシデント検出を使用した運用の回復力」に参加してサービス運用の難しさを体験した #AWSreInvent #SUP305

re:Invent2023の現地で開催された「Operational resilience using observability and incident detection」 ワークショップに参加してきましたのでレポートします。

概要

Learn how to assess operational readiness and resilience and quickly react to events using example workloads based on real-world scenarios. In this workshop, use AWS best practices, including the AWS Infrastructure Event Management (IEM) process and the AWS Well-Architected Framework, to identify and mitigate risks and operational issues. Discover how to plan for a successful launch and implement an effective observability strategy, including Amazon CloudWatch anomaly detection using statistical and AI/ML algorithms, and an incident detection strategy using services such as AWS Health, VPC Flow Logs, Amazon Route 53, and other foundational infrastructure services. You must bring your laptop to participate.

(日本語訳)実際のシナリオに基づいたサンプルワークロードを使用して、運用準備と回復力を評価し、イベントに迅速に対応する方法を学びます。このワークショップでは、AWS Infrastructure Event Management (IEM) プロセスと AWS Well-Architected Framework を含む AWS のベストプラクティスを使用して、リスクと運用上の問題を特定し、軽減します。統計的アルゴリズムやAI/MLアルゴリズムを使用したAmazon CloudWatchの異常検知、AWS Health、VPC Flow Logs、Amazon Route 53、その他の基盤インフラストラクチャサービスなどのサービスを使用したインシデント検知戦略など、立ち上げを成功させるための計画や効果的な観測可能性戦略の実装方法を発見してください。参加にはノートパソコンの持参が必要です。

このワークショップで学んだこと

• サービスの異常を検知するための実装方法
• スケーラビリティ、レジリエンスを高めるためのインフラストラクチャ設計
  • VPC や NGW,エンドポイントの可用性
• VPC フローログを活用したトラブルシューティング方法

実施したワークショップの内容

このワークショップは非常にボリュームが大きく全て実施することができずにタイムアップでした。そのため実施した範囲で私が勉強になった部分を抜粋して載せています。全体としては以下の内容が学べるワークショップです。

負荷テストの準備・確認

このシナリオで利用した負荷テストのツールはDistributed Load Testing on AWS ソリューションです。

元々デプロイされているスタックから URL を取得すると、以下のようにテスト結果の数値が確認できます。

このワークショップの題材となっているサービスでは以下の目標を掲げているため、基準に達していないことが判断できました。

目標は、1 秒あたり 2,500 件を超えるリクエストを処理し、応答時間を 250 ミリ秒以下にすることができるスケーラブルなインフラストラクチャを実現することです。

こうした負荷テストを行うことで、目標と実態の差を確認できたので適切なツールを活用していきたいですね。

CloudWatchの異常検出

このシナリオでは CloudWatch のメトリクスを使用して EC2 の CPU 使用率からアラートを出していきます。

CloudWatch アラームの設定時に知ったのですが、最近のコンソールはアラームの推奨事項なんてものがあるんですね。本番運用ではこのまま設定して終わりとはいきませんが、参考として設定できるのは嬉しいです。

ここで設定された値は固定値であり、要件に合わないため CloudWatch の異常検出機能を使ったアラーム設定に変更しました。

CloudWatch の異常検出は機械学習アルゴリズムや統計アルゴリズムから動的にベースラインを決めてくれます。そのため、最小限の労力で適切なアラーム設定ができるというシナリオでした。

これまで CloudWatch の異常検出はあまり活用したことがなかったので、色々試してみたいですね。

参考：CloudWatch の異常検出機能を利用してアラームを作成する | DevelopersIO

Amazon VPC IP Address ManagerによるIP管理とスケーラビリティ

VPC IP Address Manager を使うと、VPC 内の IP アドレスの使用率を可視化できます。ワークショップでは全ての IP を使い切った VPC を対象に実行しました。

こうした状態ではサブネットの追加などスケールできないので、スケーラビリティに問題がある状態です。

その対応として実施したのは VPC への CIDR 追加です。本来であれば IP アドレスの枯渇は設計時点から考慮すべきものですが、対応方法も存在しているので覚えておきましょう。

これでサブネット等が追加できる状態になったため、IP 枯渇のスケーラビリティの問題は解決できました。

Reachability Analyzerを用いたVPCエラーログの分析

VPC フローログ内にある REJECT されたログを Reachability Analyzer を使って分析、問題を解消していきます。

まず最初に VPC フローログを CloudWatch Logs Insight 確認していきます。

クエリで拒否されているものを絞って IP アドレス等を確認しました。ここで対象のログが特定できたので Reachability Analyzer を使って調査していきます。

Reachability Analyzer を開いて、パスの作成と分析をします。先ほど VCP フローログを調査して分かった ENI や IP アドレスを入力していきます。

VPC フローログの調査で想定した通り、到達不可能の結果が出ました。

今回の原因はセキュリティグループのアウトバウンドだったため、許可を追加することで対応できました。

こうして Reachability Analyzer を使うことで無事トラブルシューティングができました。ここまでの調査の流れは是非できるようにしておきたいですね。

おわりに

まだワークショップとしてはボリュームがあったのですが、私が実施できたのはここまででした…。まだまだ残りのシナリオもありましたが、実施できた範囲でも非常に学びがあるワークショップです。

サービスを運用する際は適切な設計を始め、異常が発生した時に通知する仕組みや対応方法が整理されているかなども検討しておく必要があります。

こうしたサービス運用の難しさを体験できた 2 時間でした。

参考

• AWS での分散負荷テスト | AWS ソリューション | AWS ソリューションライブラリ
• インフラストラクチャイベント管理 | 休日や製品のローンチに向けたスケーリングの計画 | AWS サポート
• Amazon VPC の IPv4 アドレス範囲の変更 | AWS re:Post
• CloudWatch の異常検出機能を利用してアラームを作成する | DevelopersIO